Web-Based Interaction With A Local System

ABSTRACT

Systems, methods, and computer program products for facilitating web-based interaction with a local system are disclosed. Such systems, methods, and computer program products provide an approach that allows a web client within in a web browser environment to access local hardware and local software—via a web server contained in the local system—in a local computer system. In response to a user input, the web client directs local hardware and local software to perform actions (e.g., writing files and taking pictures). Information related to such actions is returned to the web client via the local web server. The local computer system may be remotely located from the web client and such returned information may be stored and/or executed at a remote site (e.g., cloud database). Security layers may be provided to authenticate the user as well as user permissions for accessing the local computer system.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of andpriority to U.S. patent application Ser. No. 13/407,218 entitled“Web-Based Interaction With A Local System”, filed Feb. 28, 2012 byMichael Hall et. al., the entire contents of which are expresslyincorporated by reference.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to remote access interfaces andmore particularly to systems, methods, and computer program products forfacilitating web-based interaction with a local computer system.

BACKGROUND

Developers typically design Internet websites to be platform agnostic.This is done using web-based programming models, such as HTML, HTML5,CSS, representational state transfer web services, JavaScript, and thelike. Such agnostic platform design allows all website visitors (i.e.,users) to have a consistent experience regardless of the web browserapplication, computer operating system, and hardware platform employedby such various users. Similarly, web-based applications (e.g., Flashgames, video players, audio players, mortgage calculators, etc.) aredesigned such that the programming model of the web-based applicationhas a consistent experience for all users across all computingplatforms. Alternatively, the developer may choose to limit thecomputing platform(s) the web-based application may be accessed from(e.g., by enforcing a “smartphones only” or a “tablet computers only”policy).

Generally, web browsers and web browser environments provide anisolated, consistent rendering and application programming interface(API) for web-based applications that does not provide access to thecomputing device's underlying and/or local system device drivers,services, and/or operating system APIs. Rather, web-based programmingmodels provide an isolated environment in which web-based applicationcan provide a defined set of functionality across a variety of computingdevice platforms. This is because if these web-based applications'software code were freely allowed to download and execute on the user'scomputing device, the software code could maliciously expose the memory,personal data, and/or operating system resources of the local computingdevice. Thus, in order to avoid compromising the user's computing device(or even remote computing devices in network communications with theuser's computing device) from unknown, untrusted, and/or untestedsoftware code, these web-based applications often run in an isolatedenvironment within the web browser environment.

Put another way, the isolated environment described above preventsweb-based applications from accessing or making use of any underlyingoperating system services (e.g., drivers, APIs, reading and writingfiles, controlling input devices, etc.). Such an isolated environment,implemented by the above-mentioned web-based programming models, allowsweb-based applications to operate with limited, tightly-controlledresources. Thus, network access and access to the host system andoperating system services are typically unavailable and/or prohibited.

SUMMARY

This summary is provided to introduce a selection of concepts. Theseconcepts are further described below in the Detailed Description. Thissummary is not intended to identify key features or essential featuresof the claimed subject matter, nor is this summary intended as an aid indetermining the scope of the claimed subject matter.

The present disclosure provides methods, systems, and computer programproducts that facilitate web-based interaction with a local computersystem. In an embodiment, a component detects a user input made within aweb-based application (i.e., client or client application). The clientis located within a web browser environment. The user input indicates auser-desired action at a local system, such as taking a picture using alocal system's camera. In an embodiment, the local system is remotelylocated from the user's computing device. In response to the user input,the client causes its local system interface component to transmit arequest signal—based upon the user input—to the local system. The clientreceives a response signal from the local system, which containsinformation related to a requested action specified by the user input.

In an embodiment, the user input initially requests an action to betaken on local hardware and local software. Data is then transferred toa web-based service and a component of the client determines whether theclient needs to contact a remote server. If communication with a remoteserver is required, a remote server interface component of the clientsends a signal—containing desired information—to the remote server.

In yet another embodiment, security layers may be provided when a moduledetermines whether the requested action—based upon the user input—is apermissible action. Such security layers (authorization process(es)) maybe implemented via a single step or multiple steps. Further, suchauthorization process(es) may be performed on a per-application basis,per-device basis, or “all-or-nothing” basis.

Further features and advantages of the present disclosure, as well asthe structure and operation of various aspects of the presentdisclosure, are described in detail below with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present disclosure will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings in which like reference numbers indicateidentical or functionally similar elements.

FIG. 1 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

FIG. 2 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIG. 3 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIGS. 4A-B are flowcharts illustrating exemplary processes forfacilitating single-step and multi-step security methods, according toan embodiment of the present disclosure.

FIGS. 5A-B are flowcharts illustrating exemplary processes forfacilitating per-device-based and per-application-based securitymethods, according to an embodiment of the present disclosure.

FIG. 6 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIG. 7 is a block diagram of a computer system useful for implementingthe present disclosure.

FIG. 8 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

FIG. 9 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

The present disclosure is directed to methods, systems, and computerprogram products for facilitating web-based interaction with a localcomputer system.

Referring to FIG. 1, a block diagram illustrating an interrelationshipbetween exemplary components that facilitate web-based interaction witha local system, according to various embodiments of the presentdisclosure, is shown. Configuration 100 depicts local system 104containing a local web server 107, local hardware 111, and localsoftware 112 accessed by a web client 102. Local web server 107communicates with local system interface 105, local hardware 111, andlocal software 112. Web client 102 contains software modules forcontrolling operations of remote sever interface 115 and local systeminterface 105. Remote server interface 115 communicates with remoteserver 114 and local system interface 105.

In various embodiments, the methods, systems, and computer programproducts of the present disclosure provide an isolated web-basedapplication, also referred to as web client 102, operating within a webbrowser environment 103 capable of accessing local system 104.Interaction is accomplished via a local system interface 105—locatedwithin web browser environment 103—that is located within web client 102in communication with local web server 107, which is located at andoperated by local system 104. For the purposes of this disclosure,“local system” 104 is the computing device or devices that web client102 accesses.

In an embodiment, local system 104 preferably includes computing devicesequipped with local software 112 and/or local hardware 111 (e.g.,cameras; scanners; global positioning system (GPS) antennae; motors;heat, light, motion or other sensors; etc.). In an embodiment, localsystem 104 preferably includes computing devices capable of locallyreading and writing data (e.g., media player, audio/video player, etc.).In an embodiment, web client 102 communicates with remote server 114 tofacilitate a web-based service, as specified by user input 101 from user110 at a user interface screen of web client 102. In yet anotherembodiment, security layers are provided to authenticate user request(i.e., user input 101), thereby controlling access to local system 104.The authentication process limits access to local system 104 via localweb server 107.

In an embodiment, web client 102 operates within web browser environment103. In an embodiment, web browser environment 103 is a web browseroptimized for operating on a portable electronic device (e.g., mobilephone, slate, laptop, etc.). In an embodiment, web browser environment103 operates on a stationary electronic device (e.g., standalonecomputing device, enterprise computing device, workstation, etc.). Insuch an embodiment, web client 102 includes one or more local systeminterface 105 modules and remote server interface 115 modules. Thesemodules 105, 115 communicate with one or more local systems 104 andremote servers 114, respectively. Modules 105, 115 generate and sendsignals in response to directives from web client 102 and receivesignals from local systems 104 and remote servers 114, respectively.

In an embodiment, modules 105, 115 are portions of software codecontained within web client 102 for facilitating communication withtheir designated targets (i.e., local systems 104 and remote servers114). In an embodiment, local system interface 105 and remote serverinterface 115 are part of an APIs designed to allow web client 102,within web browser environment 103, to access specific local system 104services. In an embodiment, local system interface 105 module and remoteserver interface 115 module may be part of web client 102. In anembodiment, local system interface 105 contains selected portions of anAPI required to communicate with local system 104 and/or remote server114. That is, when a developer has designed web client 102 to interactwith only a portion of local system 104, it is unnecessary to implementall portions of software code to communicate with local system 104.

In an embodiment, web client 102 utilizes local system interface 105 tocommunicate with local system 104. Local system interface 105 generatesand transmits request signals 106 to local web server 107, located on,and operated by, local system 104. In an embodiment, local systeminterface 105 provides additional APIs that facilitate interaction withlocal system 104 without additional developer knowledge of the localsystem 104 configuration (e.g., HTML, HTML5, CSS, representational statetransfer web services, JavaScript, etc.).

In an embodiment, local web server 107 is a component of local system104 that allows access to local hardware 111 and local software 112 oflocal system 104. Local hardware 111 may include hardware capable ofbeing operated at least in part by a computing device. Local hardware111 may include internal and external input and output devices of localsystem 104 (e.g., cameras, scanners, global positioning system antennae,motors, sensors, etc.) In an embodiment, local hardware 111 may includedevice drivers and APIs associated with the above-listed devices. Localsoftware 112 may include all software capable of running on a computingdevice (e.g., operating system contained on local system 104 and itsservices, APIs, third-party application programs, other computingservices, etc.). In an embodiment, local software 112 includes adigital, modifiable calendar. In yet another embodiment, local software112 includes a service that facilitates reading and writing filescontained on local hardware 111.

In an embodiment, local web server 107 is a component of an operatingsystem executing on local system 104. In an embodiment, local web server107 may be a separate software program from the operating system,provided by the same and/or different developers of the operatingsystem. In an embodiment, local web server 107 accesses local hardware111 and local software 112 via application development models that havedirect knowledge of the operating system (e.g., C/C++, Win32, MFC, .NETFramework, APIs exposed through software development kits, etc.).

In an embodiment, local web server 107 is capable of returning responsesignals 109 to local system interface 105 of web client 102. That is,local web server 107 sends signals to local hardware 111 and localsoftware 112, which cause local hardware 111 and local software 112 toperform the desired action, as specified by user input 101. Localhardware 111 and local software 112 returns information—related to thedesired action—to local web server 107. Local web server 107 thengenerates response signals 109 containing information related to thedesired action, which was carried out by local hardware 111 and localsoftware 112. Response signal 109 is sent by local web server 107 tolocal system interface 105 located at web client 102 in web browserenvironment 103. These software modules allow APIs of web client 102 inweb browser environment 103 to access local system 104 and utilize thelocal system services of local hardware 111 and local software 112.

Referring to FIG. 2, a flowchart illustrating an exemplary process 200for facilitating web-based interaction with a local system, according toan embodiment of the present disclosure, is shown. In step 202, a userinput 101 is received at web client 102. In an embodiment, user input101 is from a user 110 indicating a desired action to initiate via thegraphical user interface (GUI) of web client 102. (As will beappreciated by those skilled in the relevant art(s) after reading thedescription herein, user input 101 may be communicated to web client 102by a computing device remotely located from web client 102.)

In step 204, web client 102 utilizes local system interface 105 tocommunicate with local system 104. That is, local system interface 105generates and transmits one or more request signals 106 to local webserver 107 located on local system 104.

Then, in step 206, local web server 107 returns one or more responsesignals 109 to local system interface 105 of web client 102. That is,local web server 107 causes local hardware 111 and/or local software 112to perform the desired action, as specified by input 101. Local hardware111 and local software 112 returns information—related to the desiredaction—to local web server 107. Local web server 107 then generatesresponse signals 109 containing information related to the desiredaction, which was carried out by local hardware 111 and local software112.

As will be appreciated by those skilled in the relevant art(s) afterreading the description herein, “user input 101” as described herein mayalso be a non-user initiated action. That is, for example, web client102 may be a GPS-enabled application (executing within web browserenvironment 103) with a timer that continuously queries to obtaincurrent GPS location via a remote (API) call to local system 104 (i.e.,local hardware 111).

As will be apparent to one skilled in the relevant art(s) after readingthe description herein, code implementing process 200 (and processes300-600 described below), that facilitates web-based interaction with alocal system may be part of a “standard” version of a web client 102application that ships from a developer or may be later added as part ofa update (or patch). Further, a web client 102 application utilizing anembodiment the present disclosure advantageously does not need to modifythe existing web browser environment 103. That is, in an embodiment, thepresent disclosure does not change the way that the browser 103interacts with local system 104 through existing web standards (e.g.,HTTP, XML, RESTful services, etc.). Thus, the present disclosureovercomes the “sandboxing” problem—where the browser defines thelocal-machine API surface that web-based applications may utilize,forcing device developers to modify the browser should they wish toprovide web applications access to additional hardware/software moduleson local device 104. More specifically, the sandboxing problem isovercome, in an embodiment, by leaving the browser intact and insteadconfiguring modules 105, 115 to provide an interface to local system 104or remote server 114, respectively, to expose the (additional)functionality of local hardware 111/software 112 to the web-browserbased application 102.

In one embodiment, process 200 in FIG. 2 provides access to local system104 via a representational state transfer (REST) API set.

Referring to FIG. 3, a flowchart illustrating an exemplary process forfacilitating web-based interaction with a local system, according to anembodiment of the present disclosure, is shown. More specifically,process 300 illustrates an example method of taking a picture with a webcamera located within local hardware 111, according to the presentdisclosure.

In step 302, in response to a user input 101 accepted at web client 102within web browser environment 103, a picture is saved to a web-basedservice. In an embodiment, in addition to communicating with localsystem 104, the user may also access a remote server 114. In anembodiment, remote server 114 is a computing device comprised of aprivate server, accessible by only user 110. In one embodiment, remoteserver 114 is a computing device comprised of one or more public servershosting public, web-based services such as media sharing sites (e.g.,FLICKR®), social media services (e.g., FACEBOOK®), remote data back-upservices (e.g., DROPBOX®), and location-based services (e.g.,FOURSQUARE®).

In step 304, web client 102 communicates with local system 104 inresponse to user input 101 by causing local system interface 105 togenerate and transmit a request signal 106 to local web server 107.

In step 306, in response to user input 101 of user 110, local web server107 receives a request signal 106 from local system interface 105, andthereby causes the web camera—located at local hardware 111 of localsystem 104—to take a picture. This information is collected at local webserver 107 and response signal 109—containing the information—is sentback to web client 102. In an embodiment, the only information sent backto web client 102 is the picture taken by the web camera. In anembodiment, additional information concerning completion of operation(s)is contained in response signal 109. In yet another embodiment, only aportion of the picture is returned to web client 102 in response signal109. Similarly, for embodiments where a requested action does notinvolve taking a picture, (e.g., determining a location of local system104, reading and/or writing a file, and/or utilizing local hardware 111output devices) response signal 109 contains all, some, none, or aportion of information accessed and/or generated at local system 104.

In step 308, web client 102 determines, based on user input 101, whetherit needs to communicate with remote server 114—remotely located from webbrowser environment 103—to save the picture to remote server 114 of aweb-based service. If it is not necessary for web client 102 tocommunicate with remote server 114, an output signal is sent to webclient 102 indicating to user 110 that the requested action—specified byuser input 101—has been completed in step 316. Otherwise, in step 310,response signal 109 is transmitted from local system interface 105 toremote server interface 115. That is, local system interface 105 moduletransmits at least a portion of response signal 109 containing thepicture to remote server interface 115.

In response, remote server interface 115 sends a signal containing thepicture to remote server 114 in step 312. In an embodiment, remoteserver interface 115 provides additional APIs that facilitateinteraction with remote server 114; without requiring additionaldeveloper knowledge of the configuration of remote server 114. In anembodiment, this is accomplished by providing additional APIs forweb-based development models (i.e., HTML, HTML5, CSS, RESTS, JavaScript,etc.). After the picture has been saved to remote server 114 of aweb-based service, web client 102 notifies user 110 that the requestedaction has been completed in step 314.

Referring to FIGS. 4A-B and 5A-B, flowcharts illustrating exemplaryprocesses for facilitating single-step and multi-step security methods,according to embodiments of the present disclosure, are shown. That is,processes 400, 410, 500 and 510 relate to security measures forpreventing unauthorized access to local system 104. In an embodiment,access is restricted to local system 104 via APIs providing access to alimited set of local hardware 111 and local software 112. In anembodiment, web client 102 determines whether the action requested byuser input 101 will generate an authorized request signal 106. In anembodiment, web client 102 determines whether the action requested byuser input 101 is recognized by local system interface 105. If requestsignal 106 is not an authorized signal, web client 102 will not permitrequested action.

The requested action may be authorized either in a single step as inprocess 400, or in multiple steps as in process 410. Where single-stepsecurity process 400 is utilized, a determination is made in step 402 asto whether permission has been granted to web client 102 to access localhardware 111 and/or local software 112. In alternate embodiments,permission may be granted by an administrator of a system containing webclient 102, local system 104, and/or an operating system associated withany such computing devices. Permission may also be granted at an APIlevel (e.g., oAuth or authentication using a well-known token, such asAPI-Key and Permission Flags, etc.). In an alternate embodiment,permissions may be determined and granted by web client 102 based upondigital signatures by the developer, which verifies web client 102 issafe to interact with certain classes of local systems 104.

In single-step security process 400, if permission is granted for webclient 102 to access local hardware 111 and/or local software 112, localweb server 107 allows access to local hardware 111 and/or local software112 in step 404. If web client 102 does not have permission, local webserver 107 denies access to local hardware 111 and/or local software 112in step 406. In an embodiment, web client 102 may be configured todisplay a permission status to user 110 via a GUI.

In multi-step security process 410, permission is provided to the userat multiple stages and/or access credentials are checked at multiplestages of communication between web client 102 and local system 104.When at least two steps are utilized to ensure security of local system104 is not compromised, it is first determined whether web client 102has permission to access local system 104 in step 412. If permission isnot granted, local web server 107 denies access to local hardware 111and/or local software 112 in step 418. Where permission is granted forweb client 102 to access local hardware 111 and/or local software 112,local web server 107 allows access to local hardware 111 and/or localsoftware 112 in step 414. Access credentials are then provided to localweb server 107 in step 416, thereby allowing local web server 107 toaccess local hardware 111 and/or local software 112 in step 420. In suchan embodiment, the two-level authentication process is employed asfollows: A first authentication level preferably includes web client102, wherein web client 102 files (e.g., OPC, CAB, ZIP, or EXE) aredigitally signed by the developer to verify that the application is safeto run; and a second authentication level occurs at an API level (e.g.,oAuth or authentication using a well-known token such as an API-Key orPermission Flags).

Referring to FIGS. 5A-B, authentication may be handled at least in parton a per-device-basis and/or a per-application-basis, respectively.Per-device-based security process 500 allows or denies access tospecific devices in local hardware 111. For example, authenticationprocess 500 may occur at local web server 107 which then determines atstep 502 if web client 102 may access a web camera (i.e., a localhardware 111) on local system 104. In step 504, access to the web camerain local hardware 111 is allowed only if permission has been granted.Otherwise, in step 506, permission is denied. In alternate embodiments,permission is granted to access: only one device in local hardware 111;only specific devices in local hardware 111; and/or only specificdevices by a limited set of web clients 102.

In an embodiment, per-application-based security process 510 operates ina similar fashion to per-device-based security process 500. However,per-application-based security process 510 allows or denies access tospecific applications and/or services in local software 112. Forexample, process 510 may determine if local web server 107 is allowedaccess to calendar application residing in local software 112 in step512. If so, process 510 proceeds to step 514; otherwise process 510proceeds to step 516. In alternate embodiments, permission is granted toaccess: only one application in local software 112; only specificapplication(s), while other specific applications (e.g., operatingsystem kernel) are excluded; and/or specific applications by a limitedset of web clients 102.

Various embodiments of the present disclosure utilize some or all of theabove-described security processes. When determining whether web client102 has permission to perform a specific task, an embodiment may verifywhether local web server 107, in response to receiving request signal106, is authorized to communicate with local hardware 111 and/or localsoftware 112.

Referring now to FIG. 6, a flowchart illustrating an exemplary process600 for facilitating web-based interaction with a local system,according to an embodiment of the present disclosure, is shown. Inprocess 600, steps 602-606 are executed in a similar fashion to steps202-206 described above, respectively. Then, in step 608, process 600determines whether web client 102 desires to communicate with remoteserver 114, which may be remotely located from web browser environment103. If step 608 is positive, local system interface 105 transmitsresponse signal 109—from local web server 107—to remote server interface115, and remote server interface 115 sends at least a portion ofresponse signal 109 to remote server 114, as shown in step 610.Otherwise, in step 612, an output signal is sent to web client 102indicating to user 110 that the requested action—specified by user input101—has been completed.

Referring now to FIG. 8, a block diagram illustrating aninterrelationship between exemplary components that facilitate web-basedinteraction with a local system, according to an embodiment of thepresent disclosure, is shown. Configuration 800 illustrates it is notnecessary for all components of the present disclosure to reside at thesame location. That is, in the embodiment of configuration 800, remoteserver 114 is at “location 3” 813 (e.g., a server room in California).User input 101 is entered at web client 102 residing within web browserenvironment 103 at “location 1” 811 (e.g., a laptop computer in a coffeeshop in New York City). Local system 104 is at “location 2” 812 (e.g., acomputing device in Texas). In other exemplary embodiments, some or allof “location 1” 811, “location 2” 812, and “location 3” 813 may residewithin a single address.

Referring to FIG. 9, a block diagram illustrating an interrelationshipbetween exemplary components that facilitate web-based interaction witha local system, according to an embodiment of the present disclosure, isshown. That is, configuration 900 includes specific commands that accesslocal system 104. In an embodiment, JavaScript developers useXMLHttpRequest to local API service 903 for making calls to local webserver 107. This allows web client (i.e., HTML/CSS/JavaScript-basedapplication 901) to access local device services (e.g., WriteFile topersist content from the running application, a camera API to capture animage from an on-device camera, GPS/Location Framework to obtain acurrent location, etc.). In such an embodiment, XMLHttpRequest to remoteweb service 902 and the URL http://localhost/services/camera/capture areused to obtain a photo from a web camera on local system 104. To uploada captured picture to a cloud hosted web service 906 (e.g., the FLICKR®service from Yahoo! Inc. of Sunnyvale, Calif.), the XMLHttpRequest toremote web service 902 uses URL http://api.flickr.com/services/upload/.In alternate embodiments, other operating system APIs 904 and devicedrivers 905 may be accessed and utilized in a similar manner asdescribed herein above.

Referring now to FIG. 7, a block diagram of an example computing device(or computer system) 700 that can be configured to implement variousaspects of time-managing emails, in accordance with one or moreembodiments of the present disclosure, is shown. In an embodiment,computing device 700 implements local system 104 (or any other componentof configuration 100).

Computing device 700 includes one or more processors or processing units702, one or more computer readable media 704 which can include one ormore memory and/or storage components 706, one or more input/output(I/O) devices 708, and a bus 710 that allows the various components anddevices to communicate with one another. Computer readable media 704and/or one or more I/O devices 708 can be included as part of, oralternatively may be coupled to, computing device 700. Bus 710represents one or more of several types of bus structures, including amemory bus or memory controller, a peripheral bus, an acceleratedgraphics port, a processor or local bus, and so forth, using a varietyof different bus architectures. Bus 710 may include wired and/orwireless buses.

Memory/storage component 706 represents one or more computer storagemedia. Memory and/or storage 706 may include volatile media (such asrandom access memory (RAM)) and/or nonvolatile media (such as read onlymemory (ROM), Flash memory, optical disks, magnetic disks, and soforth). Memory and/or storage 706 may include fixed media (e.g., RAM,ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flashmemory drive, a removable hard drive, an optical disk, etc.).

The techniques discussed herein may be implemented in software, withinstructions executed by one or more processing units 702. It is to beappreciated that different instructions can be stored in differentcomponents of computing device 700, such as in a processing unit 702, invarious cache memories of a processing unit 702, in other cache memoriesof device 700 (not shown), on other computer readable media, and soforth. Additionally, it is to be appreciated that the location whereinstructions are stored in computing device 700 may change over time.

One or more I/O devices 708 allow a user to enter commands andinformation to computing device 700, and also allow information to bepresented to the user and/or other components or devices. Examples ofinput devices include a keyboard, a cursor control device (e.g., amouse), a microphone, a scanner, and so forth. Examples of outputdevices include a display device (e.g., a monitor or projector),speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context ofsoftware or program modules. Generally, software includes routines,programs, objects, components, data structures, and so forth thatperform particular tasks or implement particular abstract data types. Animplementation of these modules and techniques may be stored on ortransmitted across some form of computer readable media. Computerreadable media may be any available medium or media that can be accessedby a computing device. By way of example, and not limitation, computerreadable media may comprise “computer storage media” and “communicationsmedia.”

“Computer storage media” include volatile and non-volatile, andremovable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules, or other data. Computerstorage media include, but are not limited to, RAM, ROM, EEPROM, Flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, and/or any other mediumwhich can be used to store the desired information and which can beaccessed by a computer.

“Communication media” typically embody computer readable instructions,data structures, program modules, or other data in a modulated datasignal such as carrier wave or other transport mechanism. Communicationmedia may also include any information delivery media. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example and not limitation, communication mediainclude wired media, such as a wired network or direct-wired connection,and wireless media, such as acoustic, RF, infrared, and other wirelessmedia. Combinations of any of the above are also included within thescope of computer readable media.

Generally, any of the functions or techniques described herein can beimplemented using software, firmware, hardware (e.g., fixed logiccircuitry, system on a chip), manual processing, or a combination ofthese implementations. The terms “module” and “component” as used hereingenerally represent software, firmware, hardware, or combinationsthereof. In the case of a software implementation, the module orcomponent represents program code that performs specified tasks whenexecuted on a processor (e.g., CPU or CPUs). The program code may bestored in one or more computer readable memory devices. The features ofthe present disclosure described herein are platform-independent,meaning that the techniques may be implemented on a variety ofcommercial computing platforms having a variety of processors.

As will be apparent to one skilled in the relevant art(s) after readingthe description herein, computing device 700 may be configured as anynumber of computing devices such as a game console, a portable mediaplayer, a desktop, a laptop, a server, a notebook computer, a tabletcomputer, a PDA, a mobile computer, a smart telephone, a mobiletelephone, an intelligent communications device or the like.

While various aspects of the present disclosure have been describedabove, it should be understood that they have been presented by way ofexample and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the presentdisclosure. Thus, the present disclosure should not be limited by any ofthe above described exemplary aspects, but should be defined only inaccordance with the following claims and their equivalents.

In addition, it should be understood that the figures in theattachments, which highlight the structure, methodology, functionality,and advantages of the present disclosure, are presented for examplepurposes only. The present disclosure is sufficiently flexible andconfigurable, such that it may be implemented in ways other than thatshown in the accompanying figures.

Further, the purpose of the foregoing Abstract is to enable the U.S.Patent and Trademark Office and the public generally and especially thescientists, engineers and practitioners in the relevant art(s) who arenot familiar with patent or legal terms or phraseology, to determinequickly from a cursory inspection the nature and essence of thistechnical disclosure. The Abstract is not intended to be limiting as tothe scope of the present disclosure in any way.

What is claimed is:
 1. At a computer system, the computer systemincluding a local web client operating within a web browser environmentat the computer system and including a local web server operating inassociation with an operating system of the computer system, the webbrowser environment in a sandbox, the sandbox preventing issuance oflocal resource commands to directly control local resources at thecomputer system, a method for web-based acquisition of data from a localresource at the computer system, the method executing on at least oneprocessor of the computer system, the method comprising: using aselected portion of a communication Application Programming Interface(API) to communicate a web protocol request signal to the local webserver, the local web server including an interface for translatingbetween web protocol signals and corresponding local resource commands,the local resource commands for controlling the local resource toacquire data in accordance with received web protocol request signals;and receiving a web protocol response signal from the local web server,the web protocol response signal responsive to the web protocol request,the web protocol response signal containing acquired data that wasacquired by the local web server, the local web server having acquiredthe acquired data by issuing the corresponding local resource commandsto the local resource to control the local resource to perform thespecified action at the local resource.
 2. The method of claim 1,further comprising: receiving input, the input directed to a web-basedservice running within the web browser environment, the inputinstructing the web-based service to acquire data from the localresource by performing a specified action, the web-based serviceincluding the selected portion of the communication ApplicationProgramming Interface (API).
 3. The method of claim 2, wherein receivinginput comprises receiving input requesting that data be acquired from alocal resource for delivery to a remote server; and further comprising:a local system interface transferring the acquired data within thesandbox to a remote system interface of the web client, the remotesystem interface configured to exchange data with remote servers; andthe remote system interface sending the acquired data to the remoteserver.
 4. The method of claim 2, further comprising presenting, at auser interface screen, an output based upon the input and at least aportion of the information contained in the web protocol responsesignal.
 5. The method of claim 1, further comprising determining whetherthe web client desires to communicate with a remote server remotelylocated from web browser environment.
 6. The method of claim 1, furthercomprising: a local system interface transmitting the web protocolresponse signal to a remote server interface operating within the webbrowser environment; and the remote server interface sending the webprotocol response signal, from the web client, to the remote server soas to supplement the functionality of the remote server with thefunctionality of the local resource.
 7. The method of claim 1, whereinreceiving a web protocol response signal comprises receiving a webprotocol response containing data acquire by issuing a local resourcecommand to a local hardware resource.
 8. The method of claim 1, whereinreceiving a web protocol response signal comprises receiving a webprotocol response containing data acquire by issuing a local resourcecommand to a local software resource.
 9. At a computer system, thecomputer system including a local web client operating within a webbrowser environment at the computer system and including a local webserver operating in association with an operating system of the computersystem, the web browser environment in a sandbox, the sandbox preventingissuance of local resource commands to directly control local resourcesat the computer system, a method for web-based acquisition of data froma local resource at the computer system, the method executing on atleast one processor of the computer system, the method comprising:receiving a web protocol request signal from the local web client, theweb protocol request communicated using a selected portion of acommunication Application Programming Interface (API); using aninterface to translate between the web protocol request signal and acorresponding local resource command, the local resource command forcontrolling the local resource to acquire data in accordance withreceived web protocol request signals; acquiring the data by issuing thecorresponding local resource command to the local resource to controlthe local resource to perform a specified action at the local resource;and sending a web protocol response signal containing the acquired datato the local web client, the web protocol response signal responsive tothe web protocol request signal.
 10. The method of claim 9, furthercomprising determining that the local web client has permission toaccess the local resource.
 11. The method of claim 9, further comprisingdetermining that the local web server is capable of accessing the localresource.
 12. The method of claim 9, wherein acquiring the datacomprises issuing a local resource command to a local hardware resourceto control the local hardware resource to perform a specified action.13. The method of claim 9, wherein acquiring the data comprises issuinga local resource command to a local software resource to control thelocal software resource to perform a specified action.
 14. A system, thesystem comprising one or more processors; system memory; one or moreadditional local resources; a web browser environment in a sandbox, thesandbox preventing issuance of local resource commands to directlycontrol the one or more additional local resources; a local web serveroperating in association with an operating system of the system; and alocal web client operating within the web browser environment, the localweb client configured to: use a selected portion of a communicationApplication Programming Interface (API) to communicate a web protocolrequest signal to the local web server, the local web server includingan interface for translating between web protocol signals andcorresponding local resource commands, the local resource commands forcontrolling a local resource to acquire data in accordance with receivedweb protocol request signals, the local resource from among the one ormore additional local resources; and receive a web protocol responsesignal from the local web server, the web protocol response signalresponsive to the web protocol request, the web protocol response signalcontaining acquired data that was acquired by the local web server, thelocal web server having acquired the acquired data by issuing thecorresponding local resource commands to the local resource to controlthe local resource to perform the specified action at the localresource.
 15. The system of claim 14, wherein the local web client isfurther configured to receive input from a remote server interfacewithin the web browser environment, the input indicating that a remoteserver is requesting data from the local resource.
 16. The system ofclaim 15, wherein the local web client is further configured to receiveforward the acquired data to the remote server.
 17. The system of claim14, wherein the local web client is further configured to, subsequent toreceiving the web protocol response signal, present output based uponthe acquired data at a user interface screen.
 18. A system, the systemcomprising one or more processors; system memory; one or more additionallocal resources; a web browser environment in a sandbox, the sandboxpreventing issuance of local resource commands to directly control theone or more additional local resources; a local web client operatingwithin the web browser environment; a local web server operating inassociation with an operating system of the system, the local web serverconfigured to: receive a web protocol request signal from the local webclient use an interface to translate between the web protocol requestsignal and a corresponding local resource command, the local resourcecommand for controlling a local resource to acquire data in accordancewith received web protocol request signals, the local resource selectedfrom among the one or more additional local resources; acquire data byissuing the corresponding local resource command to the local resourceto control the local resource to perform a specified action at the localresource; and send a web protocol response signal containing theacquired data to the local web client, the web protocol response signalresponsive to the web protocol request signal.
 19. The system of claim18, wherein the local web server being configured to acquire datacomprises the local web server being configured to acquire data byissuing a local resource command to a local hardware resource to controlthe local hardware resource to perform a specified action.
 20. Thesystem of claim 18, wherein the local web server being configured toacquire data comprises the local web server being configured to acquiredata by issuing a local resource command to a local software resource tocontrol the local software resource to perform a specified action.